1. Field of the Invention
The present invention relates to the automatic synthesis of executable software code from a user specification. A particular application is the automatic code generation for valuing financial instruments.
2. Description of Problem Environment
Mathematicians, physicists, engineers, and analysts who build computer programs to solve partial differential equation ("PDE") modeling problems must be familiar not only with the mathematics and physics of their problems, but also with a variety of technological tools. Pragmatically, this problem solving process involves thinking in terms of the tools, e.g., numerical software libraries, existing codes, and systems for connection software components. Unfortunately, sometimes the emphasis must shift too early from the fundamentals of the problem to how to code a solution.
Current practice generally centers around mathematical libraries that provide code modules to be connected via subroutine calls. Such libraries are limited to the specific interface required to use each module of the library.
The predominance of tool considerations can obscure the model and cause modelers to think at too low a level of abstraction. This can lead to compromises that cause inaccurate or incomplete solutions. Some difficulties are:
Insufficient understanding of the underlying mathematics may lead to a choice of numerical methods that are inappropriate to the problem, PA1 Higher-order methods tend to be avoided because they are too numerous to put into libraries and too tedious to code manually, PA1 Lack of generality or incompleteness in available libraries can cause modelers to include similar shortcomings in their own models, PA1 Unstated or poorly understood tool and component assumptions can lead to composition of software components in a way that violates their assumptions, PA1 The assembly of a solution from pre-existing components often precludes significant optimizations that span multiple components, and PA1 The assembly-of-components style of programming may also impose computing platform and language constraints not inherent in the modeling problem.
The shortcomings of conventional libraries have not escaped popular notice. To address some of the problems, both object-oriented libraries and expert systems have been proposed.
Object-oriented libraries can provide more generality by abstracting data structure representations, but they are usually not independent of the specific equations being solved or of properties such as spacial dimensionality and order of accuracy of the algorithm being used, which typically affects the data presentation. With any type of library, assembly and bottom-up optimization of individual modules is the user's focus rather than top-down decision making and global optimization.
Expert systems can select and combine library modules relieving the user of some of the programming burden. However, expert systems alone do not address issues such as an appropriate specification level, generation of arbitrary higher-order methods, global and problem-specific optimization, and platform re-targeting.
One feature common to the best of libraries and expert systems is a good analysis of the application area. Expert systems generally start at an abstract level in terms of problem solving goals or tasks and their subproblems. Eventually these tasks must connect into the specific functionality provided by the library routines. Object-oriented libraries allow this contact to be made at a more abstract level. As part of the analysis process, classifications or taxonomies of problems and solution techniques are typically developed. The analysis information may be used in the design of objects, decision or planning rules, or library routine naming schemes.
Many problems in science, engineering, or finance can be modeled using partial differential equations. While finite difference techniques are widely used for finding a solution for these PDE problems, producing accurate software code to generate a solution is difficult and time consuming. Programming such software code requires extensive domain knowledge of the problem, an understanding of the math, an understanding of advanced computer science techniques, and extensive testing and debugging. Therefore, other techniques are often used to model such problems.
For example, privately traded derivative financial products comprised a $29 Trillion industry in 1996, growing at 37% annually. Investment banks and derivative brokers make extensive use of sophisticated mathematical models to price the instruments, and once sold, to hedge the risk in their positions. The models used are basically of four types: analytical models, and three versions of approximate numerical models: Monte Carlo, lattices (binomial and trinomial trees) and finite differences.
A host of simplifications, e.g., constant interest rates, constant volatility of the underlying assets, continuously paid dividends, etc, allow analytic solutions to the Black-Scholes equation, the basic partial differential equation describing derivative securities. These analytic solutions are packaged in software libraries of "analytics". Many packages exist. They may be used by traders for rough estimates, but all the assumptions required to make analytic solutions possible, usually render them too inaccurate for pricing complex derivative products. Major investment banks usually strip them out of any integrated software systems they may buy, and substitute their own numerical models.
Monte Carlo models calculate the value of an option by simulating thousands or millions of possible random paths the underlying assets prices may take, and averaging the option value over this set. Early exercise features, i.e., American options, cannot be priced, and the values of critical hedging parameters are often noisy. Option parameters calculated in this way may converge to the correct answer quite slowly.
In lattice methods the price paths are again simulated as a discrete series of branch points, at which an asset price may go up, down, or perhaps remain unchanged. These methods are popular and quite flexible, but they require many branch points in time for accuracy, (They converge to the correct answer like 1/N, where N is the number of time samples.) and they may be very difficult to construct, especially in multiple dimensions. If the branches cannot be made to "reconnect" then the CPU time for these algorithms increases exponentially with N, rather than proportionately.
A solution based on finite difference solutions of the Black-Scholes partial differential equation and related equations is a desirable approach, but difficult to implement. Writing software solutions that solve such partial differential equations is time consuming and debugging difficult.
Another problem is that while it is widely assumed that current modeling techniques for financial processes are measured continuously, in the real financial world they are measured discretely. Often the difference is quite significant. The continuous measurement model may be too inaccurate to be useful. An example is the discrete sampling of an asset price, say at the end of a trading day, to determine if it has crossed a "barrier". Often option structure contain these barriers. An asset price crossing this barrier may "knock-out" an option, i.e, render it valueless. If a stock price crosses the barrier during the day but recrosses back before the end of trading, a continuous model of the option would be knocked out, but the discrete model would still be viable. There are similar differences between continuously and discretely sampled average and extremum prices which figure into Asian and lookback options.
Producing finite difference code which models these discrete events has been difficult in the past and been an impediment to their use, when in fact finite difference solutions have many advantages. Therefore, it would be a significant improvement to the modeling of such financial instruments if a finite difference solution were available which could account for such "barrier" dependent pricing and could be easily implemented.